QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940132.txt

Internet Message Format | 1994-11-13 | 16KB

Date: Tue, 28 Jun 94 04:30:01 PDT
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #132
To: tcp-group-digest


TCP-Group Digest            Tue, 28 Jun 94       Volume 94 : Issue  132

Today's Topics:
                      History and the Final TNC
                       Router Project (7 msgs)
                      TCP-Group Digest V94 #130

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 27 Jun 1994 10:14:40 -0700
From: [e-mail] (Jack Brindle)
Subject: History and the Final TNC
To: [e-mail]

Phil Karn says...
>>> It's no wonder that some of those contributors have disappeared from
>>> the list
>
>>Most of them graduated and went to work...
>
>Or changed jobs and started doing this stuff for real...


And that's the truth. Many of the people doing CDPD development are
escapees from the ham tcp/ip packet radio world. At the moment, CDPD
appears to be the closest "real" (no arguments please) commercial
system to what we hams are really wanting (and trying) to do. Of
course, one could argue that the ham involvement is why it looks
this way ;-).



Jack Brindle
------------------------------------------------------------------------------
ham radio: wa4fib                             internet: [e-mail]

------------------------------

Date: Mon, 27 Jun 1994 06:25:26 -0500 (CDT)
From: [e-mail] (Steve Sampson)
Subject: Router Project
To: [e-mail]

> Linux gets 56Kbit with no losses on a 386DX40 with SCSI disks, 38400 with IDE
> due to certain IDE drives needing you to lock interrupts off during a transfer
> to avoid nasty messes occuring. The code is clean and could as equally be
> shoved into DOS or anything else. Another way to attack this from the
> NOS/DOS side is to use the FOSSIL drivers.

That's not what I meant actually. I run 38400 all day long on my Procomm for
Windows (to a 14.4 modem) and it works fine.  The problem is purely the NOS
implementation.  If you put NOS on Linux it would be a dog compared to the
Linux I/O.  FOSSIL drivers (or SLIP8250 Packet Driver) don't work either, as
the block of data would still have to go through the SLIP/KISS routines which
operate at one character at a time.  What would fix it probably is routines
which pushed one Frame at a time after being processed in the background.
But I don't care enough to fix it, as Ethernet cards cost the same as serial
cards and performance is so much better.

I've been running a different version of PD Unix, but the user base never
developed.  It's frozen at about the 1991 level :-)  Guess I need to switch
to Linux.  What's a good internet source for the latest?

--
Steve

------------------------------

Date: Mon, 27 Jun 94 10:50:42 EST
From: "Ashok Aiyar" <[e-mail]>
Subject: Router Project
To: [e-mail]

On Mon, 27 Jun 1994 06:25:26 -0500 (CDT),
Steve Sampson  <[e-mail]> wrote:

>
>I've been running a different version of PD Unix, but the user base never
>developed.  It's frozen at about the 1991 level :-)  Guess I need to switch
>to Linux.  What's a good internet source for the latest?
>

I recommend the Slackware distribution over any of the others.
The home site is ftp.cdrom.com, but it is also available from
tsx-11.mit.edu, and perhaps sunsite.unc.edu

Cheers,
Ashok
(lurker who wishes he knew enough to contribute more often)

--
Ashok Aiyar                                [e-mail]
Department of Biochemistry                         Tel: [phone]
CWRU School of Medicine                            Fax: [phone]

------------------------------

Date: Mon, 27 Jun 94 09:39:55 -0500
From: [e-mail] (Steve Brown)
Subject: Router Project
To: [e-mail]

Steve Sampson writes:

> I've been running a different version of PD Unix, but the user base never
> developed.  It's frozen at about the 1991 level :-)  Guess I need to switch
> to Linux.  What's a good internet source for the latest?

The home of the Linux stuff is

  sunsite.unc.edu

in the

  /pub/Linux

directory.

IMHO, the really slick way to deal with Linux is to get one of the
CD-ROM distributions.  The most recent ones allow you to mount the
CD-ROM device and leave a lot of the stuff that you may need only
occasionally on the CD-ROM.

I have personal experience only with the Trans-Ameritech version.
There are several others.  The disk is about $30, if memory serves.
Can't touch it for $5000 in the commercial world.

Standard disclaimer about being a customer, etc., applies.  Your
mileage may vary.

73 es GL,

              *********************************************
              |  Steve Brown, WD5HCY         |            |
              |  [e-mail]   | Simplicate |
              |  [e-mail]      | and add    |
              |       [44.28.0.61]           | lightness. |
              |  wd5hcy@kf5mg.#dfw.tx.usa.na |            |
              *********************************************

------------------------------

Date: Mon, 27 Jun 1994 12:20:25 -0400
From: "Brandon S. Allbery" <[e-mail]>
Subject: Router Project
To: [e-mail] (Steve Sampson)

In your message of Mon, 27 Jun 1994 06:25:26 CDT, you write:
+---------------
| implementation.  If you put NOS on Linux it would be a dog compared to the
| Linux I/O.  FOSSIL drivers (or SLIP8250 Packet Driver) don't work either, as
+------------->8

Beg pardon?  JNOS/Linux writes full packets at a time (or as much as will go
without blocking), and reads what's available (usually 8-10 chars in nonblock
mode, up to 255 for the ALPHA.4 release's blocking mode under 1.0.x or
1.1.22+).

Actually, a FOSSIL driver won't help NOS much:  the "tx" process for the
interface already introduces buffering to limit the impact of char-at-a-time
output, the "rx" process does the same for input, and a FOSSIL driver simply
separates the char-at-a-time I/O from NOS into a separate driver.  Even Linux
uses character-at-a-time I/O at the kernel level.  The problem is the serial
port hardware interface, not the software; and the fix is an intelligent port
board that supports DMA.  Even better, one that speaks KISS framing protocol
and presents full packets with framing already handled (see next paragraph).

I grant that slip_decode() is inefficient, but a FOSSIL driver still has to do
char-at-a-time input to process KISS packets because of framing and escape
characters.  Linux does much the same to process "ICANON" mode input (think of
newline as a frame delimiter and backslash as a frame escape... not to mention
backspace, line kill, CR->NL conversion, etc.).  A hardware KISS-framing
interface that presents fully decoded packets via DMA is the only real chance
to speed things up.

| developed.  It's frozen at about the 1991 level :-)  Guess I need to switch
| to Linux.  What's a good internet source for the latest?
+------------->8

sunsite.unc.edu:/pub/Linux/distributions (I think; can't check right now)
contains several Linux distributions.  At the moment, Slackware is preferred;
Debian is still in development, MCC is rather minimal and requires quite a few
add-ons to be usable outside its target environment as a workstation on a
network, and SLS is as usual the bleeding edge that cuts both ways :-)

++Brandon
--
Brandon S. Allbery       [e-mail]         [e-mail]
Friends don't let friends load Windows NT.        Linux iBCS2 emulation

------------------------------

Date: Mon, 27 Jun 1994 19:19:55 +0200 (BST)
From: [e-mail] (Alan Cox)
Subject: Router Project
To: [e-mail] (Brandon S. Allbery)

> Beg pardon?  JNOS/Linux writes full packets at a time (or as much as will go
> without blocking), and reads what's available (usually 8-10 chars in nonblock
> mode, up to 255 for the ALPHA.4 release's blocking mode under 1.0.x or
> 1.1.22+).

You missed the point a little. JNOS keeps up overall.. KA9Q does not because
there is so much overhead in the very low level serial code. To be quite
honest compared with a top notch serial driver (which is an art form on a PC)
its awful. It does loads of nasty 8086 get back into C stuff and then makes
a lot of inefficient calls each character.

ALan

------------------------------

Date: Tue, 28 Jun 94 01:44:28 EDT
From: [e-mail] (Ron Atkinson  N8FOW)
Subject: Router Project
To: [e-mail]

>Windows (to a 14.4 modem) and it works fine.  The problem is purely the NOS
>implementation.  If you put NOS on Linux it would be a dog compared to the
>Linux I/O.  FOSSIL drivers (or SLIP8250 Packet Driver) don't work either, as

As many people know I've been messing with Linux here at home on packet.
After all kinds of various tests what I've found is that for regular
everyday packet at 9600 and 1200 bps Brandon's JNOS/Linux seems to work
the best. Compared to a DOS version of JNOS, it blows them away anyday
for spe. I've beaten the JNOS 1.10 series into the ground and found that
the Linux version of JNOS has faster mailbox files than the 1.10 indexing
code (yes it does too). Plus under the latest DOSEMU (version .52) JNOS
even runs faster under that than under a regular DOS box, but it isn't
stable enough for regular operation.  My JNOS/Linux hasn't locked up yet
(I don't believe in doing any kind of timed execution under any version of
NOS either to reboot the machine. If it can't hold up on it's own then
dump that version) and it's operation is better than any DOS version.
     I also ran the AX.25 code in the kernel and that ran good as long
as there are no retries. Part of the reason for NOS is that it's designed
to operate in a shared environment like amateur packet radio is. Some people
forget this when they operate Windows, Unix, and other operating systems or
GUI interfaces over packet.  I ran a bunch of tests in my shack and over
the air on packet and found that both JNOS/Linux and Linux AX.25 kernel
were about the same in a controlled environment (a pair of TEKK radios
and Paccomm G3RUH modems at 9600), but on packet and sharing a frequency
with others and having varying round trip times running JNOS/Linux was the
only way to go.
     I have since changed my system around so that n8fow.ampr.org is my
Linux OS and roseville.ampr.org is my JNOS which is talking to the tnc's.
Linux and JNOS are talking over a pty and there is a proxy arp on the JNOS
for my Linux side. Linux operates slightly better now over packet by having
JNOS on the front end.  This is the equivalent of those people running
Windows on one machine and having JNOS on another talking to the tnc's. If
someone did a hack and got Windows to talk directly to a tnc without having
capability of round trip timer calculation then they might be surprised at
how poorly it would work (except in a point-to-point link environment).
     As I said before, my tests were done in house and on packet at both
1200 and 9600 baud. I'd like to hear how well 56k does though with both
JNOS and Linux AX.25 kernel (or PI2).

     BTW, for those running a pty between JNOS and the Linux OS, if you
do experience is running sluggish make sure your trace is OFF on that
port (no reason to run it anyways except for debugging). My setup is
running a 38400 SLIP link and a sample ftp with the trace off is:

ftp> get j109lxA4.tgz
200 Type set to I.
200 PORT command successful.
150 Opening BINARY mode data connection for j109lxA4.tgz (639267 bytes).
Bytes recv : 639168
RETR j109lxA4.tgz: 639267 bytes in 29 sec (21456/sec)
226 Transfer complete.
ftp>

With the trace on it's:

ftp> get j109lxA4.tgz
200 PORT command successful.
150 Opening BINARY mode data connection for j109lxA4.tgz (639267 bytes).
Bytes recv : 639168
RETR j109lxA4.tgz: 639267 bytes in 614 sec (1040/sec)
226 Transfer complete.
ftp>

I know that some people have a habit of turning every feature on whether
it's needed or not. This is an example of how a not needed feature (a
trace on a pty during normal operation) can seriously hurt performance.

Ron N8FOW

------------------------------

Date: Tue, 28 Jun 94 02:59:02 EDT
From: [e-mail] (Ron Atkinson  N8FOW)
Subject: Router Project
To: [e-mail]

>Ron, I don't understand this.  If you're running at 38400, then the BEST you
>could do is 3,840 bytes/second.

I always thought the thruput in NOS was measured in bytes/sec too.
I just did an ftp from Linux to the JNOS/Linux and this is what I got:

ftp> get j109lxA4.tgz
200 Port command okay
150 Opening data connection for RETR /home/ftp/pub/Linux/JNOS/j109lxA4.tgz (639267 bytes)
226 File sent OK
639267 bytes received in 25.2 secs (25 Kbytes/sec)
ftp>

If the pty runs faster than 38400 then heck, I'm not complaining  :-)




>p.s. I was also a little confused; why do you need the other JNOS talking to
>the TNCs; why not have the linux/jnos talk to the TNCs directly?

Actually this is what I'm doing now.  I sometimes forget to distinguish
between JNOS/DOS and JNOS/Linux. I've just about given up on JNOS/DOS
except for Dougs 1.08dfd which I run on the hamgate. Just getting tired of
chasing problems in the code and porting applications over that are already
written for Unix. JNOS/Linux's main jobs are to provide a way for users to
reach me (mailbox and ttylink server) and to run the TNC's.


>-Mike

Ron N8FOW

------------------------------

Date: Mon, 27 Jun 1994 18:19:17 -0800 (PDT)
From: [e-mail] (John Paul Morrison)
Subject: TCP-Group Digest V94 #130
To: [e-mail]

>
> Date: Sat, 25 Jun 1994 10:34:44 -0500 (CDT)
> From: [e-mail] (Steve Sampson)
> Subject: Routing Project
> To: [e-mail]
>
> Alan Cox reports that his group is nearing completion of a Linux design
> that could run in 2 Meg and a floppy.  I like this idea much better, being
> an advocate of using better code.  For example the TCP/IP is probably no
> better than Phil's, but the support code is (domain, NFS, etc).  Hopefully
> they will be able to release a floppy image.

I put together a boot floppy image a while ago; it's a Linux 1.1
kernel, but it is not the latest release. I put it together so people
could play with the Ottawa PI2 card Linux device driver. If there's
demand, I can update the image to the latest, greatest kernel and ax25
code. It should be on hydra.carleton.CA in the incoming directory, or
moved to a Linux/PI directory.

The kernel on the floppy is compiled with WD/SMC ethernet card
support, Ottaw PI2 card, the Linux ax.25 code; SLIP and NFS should be
there too. If you don't have a PI card, you can still use a TNC
through a serial port.  Not bad for one 1.44meg boot floppy. I can't
say if it will boot in only 2 megs, but it will boot in 4 megs or
more.  I haven't updated it because noone seemed interested. (I can
update it, and it also needs a separate README, there's only so much
help info I can stuff on the boot disk.)

---------------------------------------------------------------------------
BogoMIPS Research Labs  --  bogosity research & simulation  --  VE7JPM  --
[e-mail] [e-mail] [e-mail]
---------------------------------------------------------------------------

------------------------------

End of TCP-Group Digest V94 #132
******************************